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Preface 


PCVR  is  a  magazine  for  homebrew  Virtual  Reality  experimenters.  We  do  not  review  extravagant 
$50,000  head-mounted  displays  or  have  interviews  with  CEOs  of  companies.  We  do  try  to 
provide  enough  information  to  our  readers  so  that  they  can  become  familiar  with  the  world  of 
Virtual  Reality.  This  commitment  brings  incredible  challenges  that  are  difficult  to  meet.  We 
publish  six  issues  per  year.  There  is  basically  six  weeks  between  each  issue  for  research  by  the 
authors.  The  last  two  weeks  are  spent  cleaning,  editing,  and  arranging  the  articles  for  the  final 
publication.  We  recently  changed  our  printing  format  and  binding  procedure  which  makes  those 
last  two  weeks  very  busy  in  order  to  produce  the  magazine  in  a  timely  manner. 

WRITING 

I  understand  that  many  of  you  are  using  this  publication  and  other  information  sources  to  create 
VR  equipment.  There  are  many  programmers  out  there  creating  virtual  worlds  which  should  be 
recognized  and  applauded.  Why  not  share  those  things  with  others.  I  worried  about  someone 
stealing  my  ideas  or  programs.  However,  I  feel  that  sharing  will  greatly  benefit  everyone  in  the 
process  of  getting  Virtual  Reality  off  the  drawing  boards.  Here's  an  example. 

At  the  time  IBM  introduced  the  PC,  they  allowed  anyone  to  "copy"  the  architecture  and  BIOS. 
We  all  know  the  results.  Clone  manufacturers  began  offering  compatibles  at  a  much  cheaper 
price.  The  PC  became  so  inexpensive  that  people  wanted  better,  faster  machines.  By  allowing 
themselves  to  be  copied  and  creating  competition,  IBM  helped  the  world.  Apple  kept  the  Apple 

II  line  and  the  Macintosh  locked  up  tight  and  only  until  recently  a  clone  of  the  MAC  has 
appeared.  By  not  sharing  the  information,  progress  was  slowed.  I  guess  what  I  am  trying  to  say 
is  "share  your  experience  and  knowledge".  We  can  all  learn  from  it  and  prosper  at  a  faster  rate. 

When  it  comes  to  writing  an  article,  you  do  not  have  to  be  a  poet  or  even  an  experienced  writer. 
You  must  possess  a  desire  and  passion  to  contribute  your  ideas  to  a  "technological  embryo" 
waiting  for  birth. 

NEXT  YEAR 

I  need  to  hear  from  you  about  the  specific  topics  that  you  would  like  us  to  cover  next  year.  You 
can  let  us  know  by  filling  out  the  enclosed  survey. 


The  current  schedule  for  1993  is: 


Jan/Feb 


I/O  Hardware 


Mar/Apr       Virtual  World  Objects  -  action  figures 

May/Jun        Virtual  World  Object  Manipulation  -  collision  detection 

Jul/Aug         Virtual  World  Toolkit 

Sep/Oct         Virtual  World  Operating  System 

Nov/Dec        Remote  Virtual  World  Access 
Clearly,  the  theme  for  next  year  is  Software.  What  do  you  think? 
DISKETTE 

You  may  have  noticed  a  new  addition  to  PCVR  magazine.  A  diskette  is  now  included  containing 
the  source  code  for  programs  in  the  issue.  In  addition,  there  are  compiled  executables  You  no 
longer  need  to  type  in  programs.  This  diskette  will  be  included  in  all  issues  after  and  including  the 
fourth.  We  hope  you  enjoy  being  able  to  execute  programs  as  soon  as  you  get  an  issue. 

SURVEY 

Enclosed  you  will  find  a  survey  sheet.  We  would  appreciate  it  if  you  would  answer  the  survey 
told,  staple,  and  mail  back  to  us.  We  are  committed  to  bringing  our  readers  the  very  best 
information  possible.  Your  time  is  greatly  appreciated. 


Joseph  D.  Gradecki 
Publisher 
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The  Power  of  Rend386 


In  January  1992,  a  public  domain  3D  graphics  system  was  introduced  to  the  Virtual 
Reality  community.  Ever  since  that  time,  Rend386  has  improved  and  become  an  excellent 
graphics  foundation  for  any  type  of  VR  programming.  Rend386  is  written  by  Dave  Stampe  and 
Bernie  Roehl.  This  article  documents  the  progression  from  Rend386  version  1.01  to  Rend386 
version  3.01    The  following  articles  describe  the  enhancements,  features  added,  and  the  ease  of 
use. 

Rend386  Version  1.01 

Rend386  is  a  3D  graphics  package  designed  for  use  with  the  80386  or  80486  personal 
computer  with  a  VGA  video  system.  The  Rend386  Version  101  system  utilizes  the  EGA  320  x 
200  x  16  graphics  display  mode.  The  initial  system  included  a  development  package  and  a  demo 
program. 

Demo 

The  demo  program  provided  an  opportunity  to  comprehend  the  initial  power  of  this 
package.  Using  a  bishop  and  banana  scene,  the  user  is  able  to  change  many  aspects  of  the  demo. 
The  main  form  of  movement  in  this  demo  program  is  the  changing  of  the  eyepoint.  Using  the 
arrows  or  joystick,  you  moved  about  the  objects  in  the  scene.  Some  simple  command-line  options 
allowed  the  eyepoint  to  be  maneuvered  to  any  viewing  position.  There  were  XYZ  and  polar 
viewing  modes  as  well  as  a  wireframe  mode. 

Development  System 

The  development  system  included  with  the  first  release  gave  the  programmer  what  he 
needed  to  create  a  VR  program.  Functions  were  defined  for  the  Tenderer,  object  creation,  and 
manipulation,  the  system  lacked  a  clear  explanation  of  how  to  use  the  functions.  The  only  guide 
was  the  demo  program  itself  This  program  turned  out  to  be  sufficient  for  the  first  release. 
Several  things  were  missing  of  course.  There  was  no  way  to  directly  manipulate  the  objects. 
Now  in  the  Virtual  Reality  program,  it  may  not  be  necessary  for  the  objects  to  move.  For 
instance,  when  walking  through  a  building,  we  are  the  only  moving  thing.  Rend386  gave  us  this 
ability  by  allowing  us  to  change  the  view  parameters. 

Speed 

The  Rend386  document  files  gave  some  initial  statistics,  "..a  512-polygon  scene  can  be 
rendered  at  speeds  up  to  15  frames/second  on  a  486/25;  this  corresponds  to  a  speed  of  over  7000 
polys/second."  I  wanted  to  test  the  speed  of  each  version  of  Rend386  so  I  changed  the  demo 
program  to  indicate  its  relative  speed.  In  the  demo  program  there  is  a  loop  similar  to: 

while  (  running  )  {} 
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In  this  loop,  I  inserted  a  redraw  =  1  statement  so  that  each  iteration  of  the  loop  would 
force  a  redraw  of  the  screen.  I  added  a  counter  called  total  that  is  used  to  count  the  total  times 
the  renderer  routine  is  called.  At  the  beginning  of  this  loop,  the  system  time  is  calculated  and  at 
the  point  the  user  presses  the  q  key,  the  system  time  is  again  calculated.  The  values  I  received  for 
the  5 12-polygon  bishban.plg  object  file  are: 

Start  time  =  19:55:22:75 
End  time       =  19:56:19:82 

This  is  a  total  of  roughly  57  seconds.  The  renderer  was  called  a  total  of  396  times.  A  little  math 
gives  us  approximately  7  screens  per  second  on  a  25-mhz  80386  with  no  processor  cache  and  no 
coprocessor.  Not  bad  but  obviously  this  machine  is  not  appropriate  for  a  real-time  Virtual  Reality 
program. 


Rend386  Version  2.01 

In  April  1992,  Dave  and  Bernie  released  the  second  version  of  Rend386.  This  version  was 
vastly  superior  to  the  previous.  The  package  included  the  demo  program  and  the  development 
kit. 

In  the  early  part  of  May,  we  saw  the  introduction  of  a  teaser  package.  This  package 
included  a  Sega  glasses  demo  program  using  the  next  version  of  Rend386  became  available. 
PCVR  covered  this  demo  package  in  Issue  3.  The  major  enhancements  to  Rend386  were: 

*  Figures  using  segments 

*  Direct  object  manipulation 
256  Colors! 

*  Expanded  documentation 

*  PLG/FIG  file  I/O 

*  PCX  picture  inclusion 

*  Pointer  facility 

*  Reflection  capability 

*  Shading 


Demo 

The  Rend386  demo  program  seemed  to  be  a  direct  response  to  the  Vectdemo  program 
that  hit  the  network  around  the  same  time.  To  illustrate  the  full  capability  of  the  new  version  of 
Rend386,  the  user  loads  a  figure  file  called  body.fig.  This  figure  is  a  robot  with  head,  chest,  arm: 
and  legs.  Using  the  mouse,  the  user  selects  any  of  the  body  parts  to  control.  Once  highlighted, 
the  user  presses  Z  for  a  comprehensive  menu  of  manipulation  functions.  (I  found  the  best  one  to 
be  twirl.)  Once  an  option  is  selected,  the  mouse  can  be  used  to  control  the  direction  the  body 
exhibits.  Talk  about  fast!  The  available  manipulation  functions  are  taken  from  the  demo2.doc 
documentation  file  of  Rend386: 
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M  ~  moves  objects  around  in  3D,  tracking  the  mouse.  Moving  the  mouse  horizontally  or  vertically  moves  the  selected  objects  in  the 

same  direction;  moving  the  mouse  vertically  while  holding  down  the  right  mouse  button  moves  the  selected  objects  away  from 
you  or  towards  you.  Clicking  the  left  mouse  button  "places"  the  objects,  but  leaves  them  selected. 

R  ~  rotates  the  objects  around  in  3D,  tracking  the  mouse  (much  as  for  the  'M'  operation  described  above). 

T  ~  "twirl"  is  similar  to  rotate,  but  instead  of  controlling  the  actual  rotation  the  mouse  now  controls  the  speed  of  rotation  about  each  of 
the  three  axes. 

I  --  gives  you  information  about  the  selected  objccl(s),  including  the  number  of  objects  that  have  been  selected,  the  total  number  of 
vertices,  and  the  total  number  of  polygons. 

C  —  copies  the  selected  object(s) 

D  --  deletes  the  selected  object(s) 

S  —  saves  the  selected  object(s)  to  a  file 

A  —  alters  an  object  or  figure's  surface  attributes  (see  "colors.doc"  for  details) 

P  --  painls  all  the  selected  objects  in  the  current  color  and  surface  type  (see  the  color  selection  menu  described  below) 
H  -•  "hacks  ofl"  (i.e.  disconnects)  a  segment  from  its  parent  segment 
J  -  joins  a  segment  to  another  segment,  which  becomes  its  parent 

F  -  pops  up  a  "figure"  menu,  which  lets  you  select  the  entire  figure  of  which  the  selected  object  is  a  part,  or  obtain  information  about 
the  figure  of  which  the  selected  object  is  a  part,  as  well  as  saving  or  deleting  the  entire  figure. 

U  —  unselects  all  the  selected  objects 


Developer  System 

The  Rend386  system  would  be  incomplete  if  we  didn't  have  the  ability  to  do  any  of  the 
object  manipulations  listed  above  ourselves.  The  new  developer  kit  gives  all  the  functions 
necessary  to  create  any  type  of  VR  program.  The  eyepoint  and  objects  both  move.  In  addition  to 
the  additional  functions,  the  documentation  is  clear.  Each  of  the  functions  are  grouped  into  a 
major  function  and  give  a  brief  description  of  their  use.  The  most  important  part  of  the  kit  is  the 
demo  program  source  code.  This  code  is  absolutely  essential  when  trying  to  use  the  kit.  The 
authors  have,  strived  to  include  the  use  of  about  every  function  in  the  demo  program.  Practice  on 
reading  C  code  because  it  will  be  necessary  for  using  the  kit. 

Speed 

Again,  I  measured  the  speed  of  the  Tenderer  in  this  second  version.  I  used  the  same  demo 
program  in  this  version  and  received  the  following  data. 

Start  time  =  21:31:38:71 
End  time       -  21:32:47:42 

This  is  a  total  of  70  seconds.  The  total  number  of  redraws  is  503  ;\  >r  a  total  of  7  2  screens  per 
second.  The  test  program  was  compiled  using  the  16  colors  libraries  in  the  Version  2  01  kit.  For 
a  further  test  of  the  speed,  I  compiled  the  test  program  with  the  25<i  color  libraries   (Note  that 
the  system  uses  the  VGA  320  x  200  x  256  mode  for  256  color;    The  following  data  was 
received: 


6 


Start  time  =  21:21:27:01 
End  time       -  21:23:30:97 

This  is  a  total  of  124  seconds.  The  total  number  of  redraws  is  801  for  a  total  of  6.4  screens  per 
second.  Obviously  there  is  a  cost  for  256  color  support,  but  not  much. 

Rend386  -  Version  3.01 

The  system  became  professional  with  this  release.  There  are  not  many  major 
enhancements  made  to  this  version  of  Rend386,  but  quite  a  few  little  improvements.  The  major 
additions  are: 

Sega  3D  glasses  support 
PowerGlove  support 
Stereoscopic  Viewing  support 


Selectable  object  sorting 
Fast  view  calculations 
Segment  numbering 
Segment  limits 

Demo 

The  demo  program  did  not  change  much  from  the  second  version  except  for  the  added 
support  for  the  glasses  and  the  glove.  The  user  has  the  option  of  setting  their  interocular  distance 
and  choosing  the  sorting  type. 

Developer  Kit 

As  with  the  other  versions,  if  the  demo  program  can  do  it  -  you  can  too!  The  developers 
kit  is  very  complete.  If  you  have  been  using  the  previous  version  in  your  programming,  I 
recommend  reading  the  new  documentation  and  comparing  it  with  the  old  in  order  to  spot  the 
new  additions. 

I  think  one  of  the  biggest  improvements  is  the  ability  to  select  segments  by  name  or 
number.  In  a  program  I  wrote  for  the  version  2.01, 1  had  to  manually  search  the  figure  tree  to 
find  the  segments  to  manipulate.  With  this  addition,  one  assigns  numbers  to  the  segments.  This 
makes  life  much  simpler. 

This  version  includes  the  stereoscopic  information  and  functions.  This  is  very  important 
for  use  with  head  mounted  displays  in  order  to  create  the  correct  images  for  each  eye.  The 
authors  deserve  a  standing  ovation  for  the  work  and  effort  in  providing  this  support  for  us. 


* 

The  little  improvements  are: 

* 
ft 
ft 
ft 
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Speed 

We  applied  the  same  test  with  the  demo  program  in  the  third  release.  The  numbers 
obtained  are: 


For  the  16  color  test: 


Start  time 
End  time 


=  22:08:45:34 
-  22:07:30:25 


This  is  a  total  of  75  seconds.  The  total  redraws  is  463  for  a  total  of  6.2  screens  per  second. 
For  the  256  color  test: 


This  is  a  total  of  61  seconds.  The  total  redraws  is  351  for  a  total  of  5.8  screens  per  second. 

Rend386  -  Version  4.01 

In  an  email  conversation  with  Dave  Stampe,  I  found  out  that  the  fourth  version  of 
Rend386  may  include:  a  set  of  rooms  for  walkthroughs,  "splits"  or  BSP  trees  for  wall  visibility, 
areas  -  world  divisions  for  dynamic  loading  of  scenes,  timed  running  of  events  for  motion  ,  and 
the  possibility  of  walkthrough  demos.  No  indication  was  given  about  a  possible  release  date. 


Rend386  is  a  professional  package  for  3D  graphics.  I  encourage  anyone  who  uses  the  PC 
for  VR  work  to  begin  using  this  package.  We  need  to  let  the  authors  know  that  their  work 
contributes  a  great  deal  and  that  it  is  being  utilized.  The  third  release  is  not  the  last  version  of 
Rend386.  Another  version  4.01  will  be  released  in  the  near  future,  so  look  for  it. 


Start  time 
End  time 


=  22:05:50:01 
-  22:04:48:88 


Conclusion 


Your  Advertisement  Here 


There  are  several  Places 
throughout  the  issue  where 
You  or  Your  company  can 


place  an  advertisement. 
The  rates  are  extremely 


reasonable.  This  Ad  would 


cost  $4.00  per  issue  for  a 
total  of  $24.00  a  year. 
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Rend386  Program  Skeleton 


Programming  using  Rend386  can  be  a  consuming  job  when  you  consider  the  time  required 
to  digest  the  demo  program.  In  this  article,  we  set  the  foundation  for  a  program  skeleton  that  you 
can  use  when  creating  Rend386  programs. 

Includes 

Every  program  written  with  Rend386  needs  the  following  minimal  include  statements: 

#i  11  elude  <stdio.h> 
^include  <stdlib.h> 
#include  "rend386.h" 

The  include  file  rend386.h  contains  the  definitions  for  the  majority  of  the  function  in  the 
library  and  several  #defines.  Next  we  set  up  a  VIEW.  This  standard  view  can  be  changed  at  will. 
Views  are  created  from  a  structure  called  VIEW.  These  structures  have  the  following  fields: 

Eye  position  -  ex,  ey,ez 
pan,  tilt,  roll 

zoom  -  multiply  by  65536L 

Light  position  -  lx,ly,lz 

Screen  size  -  left,  right,  top,  bottom 

Clipping  values  -  hither,  yon 

Aspect  ratio  -  Multiply  by  65536L 

Flags 

Screen  offset  -  x,  y 

View  Transformation  Matrix 


Let's  declare  a  view  with  the  following  parameters: 

*  Eye  at  0,  0,-10000 

*  0  Pan,  0  Tilt,  and  0  Roll 

*  0  Zoom 

*  Light  at  1000,  1000,  -10000 

*  Full  320  x  200  screen 

*  Clipping  values  of -5000  and  5000 

*  Aspect  ratio  of  1/1.25 

*  All  Hags  off 
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The  resulting  structure  would  appear  as: 


static  VIEW  ourview  =  {    0,  0,  -1000, 

0,  0,  0, 


0, 

1000,1000,-10000, 

0,319,0,199, 

-5000,5000, 

1/1.25*65536L, 

0 


}; 


The  functions  that  use  the  view  require  a  pointer  to  the  memory  location  containing  the 
view  parameters. 

static  VIEW  *current_view; 

Global  Variables 

There  are  several  global  variables  used  in  the  skeleton.  We  present  them  here  to  keep  the 
order  of  the  program.  They  are  documented  in  the  remaining  sections  of  the  article. 

static  int       visual  page  =  0, 

shifted  =  0; 
extern  int  screenclearcolor; 

int  execution  =  1, 

redraw  =  1; 


Main  Function 

We  skip  over  a  few  functions  to  discuss  the  main  function.  The  main  function  looks 
something  like: 

main(){ 

setup_render(); 
currentview  =  &our_view; 
compute_view_factors  (  currentview  ); 
atexit(closeall); 

if  (enter_graphics())  { 
fprintf  (  stderr,  "could  not  enter  graphics  mode\n\n"); 
exit(l); 

} 
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screen_clear_color  =  0; 
redraw  =  1; 

main_loop();  /*  start  us  off  V 

> 


The  f'rst  steP  » t°  setup  the  tenderer.  The  function  setup  render  initializes  internal 
tructures  and  prepares  the  system  for  rendering  objects.  We  set  our  view  pSSShe 
location  of  static  VIEW  stmcture  we  created  eartier.  This  pointer  is  given  to  he  funct  on 
compute_v,ew_factorS.  This  function  calls  two  functions  initialize  screen   a  t^T  nd 
fast  v,ew_factorS  The  first  function  sets  up  the  VIEW  stuicture  gi^en  to  if  Th Second 
fi.nct.on  computes  internal  values  based  on  the  current  settings  of  the  VIE^  stic  ure  The 
library  documentation  gives  further  information  on  these  functions 

has  finishU6  W  Tm  ateXit  '''I8      ™-tlme  SyStem  What  Procedure  10  «1I  once  the  program 
has  fimshed.  We  have  g.ven  ,t  a  function  called  closeall  which  will  be  exnlain  shortlv  w  ? 
the  graphics  mode  after  executing  all  of  these  statements  P  *  W' 

Screen_cIear_coIor  is  an  external  variable  in  the  Rend^Sfilihram,  tka     +  i 
screen  to  the  color  specified  by  this  variab.e.  We  set  ££2^  ^TJZt' 

stuld  b      7  S6t;  gl°ba'  Variab'e  Ca"ed  redraW  e"Ual  10  one-  ™S  indicates  ha?a  redraw 

ribrntrore°snyZossib,e  The  end  °f  the  main    *  -  -  ^:P(), 


Main  Loop  Function 

This  function  is: 


void  main  loop()  { 
while  (  execution  )  { 

if  (  bioskey(l)  ){handle_key  (getkey());} 
if  (redraw)  new_display(); 


vanablet^s  ."hi  p^m'  ^  ™s 

.draws,  keyboard  alify,  and  any  l^^^^tZ^Z 

i.  the  JL^^fi^^.^  "  Cfia"      T'0"  ha"d,e-key  Md  ^ 

distributed  with  Rend386  I  originally  tried  to  us  Sand  C  "T  ^  ^  dem° 

hung  the  system  so  I  use  this  one  3  d  °  r°UtmeS  t0  retUrn  the  k^  but  they 


unsigned  getkey(){ 
unsigned  c; 
union  REGS  regs; 


I! 


regs.h.ah  =  2; 

int86(0xl6,  &regs,&regs  ); 

shifted  =  (regs.h.al  &  3); 

if  ((c=bioskey(0))  &  Oxflf)  c  &=  Oxff; 

else  if  (  shifted  )  c  |=  1; 

return  c; 

} 


The  key  value  returned  by  this  function  is  given  to  the  function  handle_key. 

void  handle  key  (  unsigned  int  c  ){ 
switch  (  c  )  { 
case  'q': 

case  *Q*:     popmsg  (  "Do  you  wish  to  quit?  (y/n)"  ); 

if  (  toupper(getkey())==  Y'  )  execution  =  0; 

else  redraw  =  1; 

break; 

} 

i 

value  oJSl  £TT  15  merely  3  SWitCH  ?temem  th3t  reSp°nds  t0  3  ^  Press  and  «he  ass™ated 
value  of  the  key  At  a  mm.mum,  we  need  a  way  to  exit  the  program.  If  the  key  pressed  is  a  -q-  or 

a  Q  the  program  d.splays  the  message  "Do  you  wish  to  quit?  (y/n)".  If  the  value  returned  is  V 

hen  the  vanable  execut.on  ,s  set  to  0  and  the  program  ends  on  the  next  go  around.  Otherwise  ' 

the  vanable  redraw  »  set  to  1  to  indicated  that  the  screen  needs  to  be  refreshed. 

th,  l  Tjn  '°°P  CheckS  the  keyb0ard'  il  checks  ,he  val"e  of  redraw  If  the  value  is  0 

^lS^^£  -  deCiSi0"-  " ^  ^  iS     ^  ,s' 


void  new_display(){ 

if  (  ++visual  page  >  1  )  visual  page  =  0; 

clear  display  (  visual  page  ); 

set_drawpage  (  visual_page ); 
.  render  (  objlist,  current  view  ); 

set_vidpage(  visual  page,  0  ); 

redraw  =  0; 

} 


It  performs  a  page  switch  and  redraws  the  screen.  We  use  two  pages  in  the  function  above 
There  are  four  avanable.  The  new  page  is  cleared,  set  to  draw,  and  the  serene  rendered  Once 
he  scene  .s  rendered,  we  show  the  page  to  the  user  with  the  statement  set  vidpage  Redraw  is 
set  to  zero  to  indicate  that  the  screen  has  been  redrawn.  " 
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Closeall 

Once  the  user  presses  the  Q  key,  and  they  wish  to  exit,  the  closeall  function  is  called. 

void  closeal!(){ 
exit_graphics(); 
reset_render(); 
exit(O); 

} 

We  exit  graphics  mode  with  the  statement  exit_graphics  and  shut  down  the  Tenderer  with 
reset_render.  This  function  frees  all  internal  structures  and  other  occupied  memory.  The 
program  halts  with  the  statement  exit(O); 

Conclusion 

This  is  the  minimum  program  necessary  for  a  Rend386  program.  Notice  that  the  render 
function  call  needs  an  object  list  in  order  to  render  a  scene.  The  articles  in  the  remaining  part  of 
the  issue  use  the  skeleton  above.  The  full  skeleton  is  listed  next. 
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siereuv.obj:    siereov.c  1  end386.li 
bcc  ~c  -ml  stereov.c 

mathinit.obj:  mathinit.c  tend386.Ii 
bcc  -c  -ml  mathinit.c 

These  lines  will  compile  the  code  in  stereov  and  rnathinit  for  the  library  the  makefile 
builds.  Without  these,  it  cannot  build  the  appropriate  libraries. 

Programs 

The  simpliest  way  to  compile  program  with  Borland  C  products  is  to  create  a  project  file. 
This  is  done  by  selecting  the  project  menu  from  the  top  of  the  Borland  environment  menu.  Enter 
the  name  of  the  project  (  and  resulting  executable  file  ).  The  environment  file  will  ask  for  the  files 
to  include  in  the  project.  Enter  the  name  of  the  source  file  and  the  following  files: 

fig.c  or  fig.obj 
rend386.!ib 
userint.lib 
demo.lib 

b!K256.Sib 
s>3£.e.  or  (jfg.obj 
color?5i6.c  or  rffior256.ohj 

•     :o  ihk.  '.Miiic  anJ  rv  nemo  ,~; "  oam,  >t       ...l       .-.:;iv  Uk\-i 
color  mode,  replace  ute  blit256  lib  with  bh; .  b  lib  ^iki  .;olorl:56  c  with 


necxk-^.  \l  you '^re  usl:^  : 
color  1 6.c. 
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Creating  Objects  in  Rend386 


One  of  the  most  powerful  features  of  Rend386  is  its  ability  to  use  objects.  A  object  is 
basically  a  set  of  vertices  and  polygons.  The  vertices  are  XYZ  locations  in  the  object's  coordinate 
space.  The  total  number  of  vertices  make  up  the  entire  object.  Individually,  the  vertices  are  used 
as  parts  to  polygons.  The  polygons  give  the  actual  shape  to  an  object.  Besides  vertices  and 
polygons,  most  objects  have  a  name,  owner,  and  a  set  of  flags. 

Creation 

The  new_obj  function  creates  an  object.  The  format  of  this  function  is 

OBJECT  *new_obj  ( int  TYPE,  int  NumVertices,  int  NumPoIygons,  char  *NAME  ) 

TYPE  refers  to  a  feature  that  is  currently  not  used  in  the  function.  NumVertices  is  the 
total  number  of  vertices  used  in  an  object.  This  value  must  be  correct  before  the  function  is 
called.  If  you  try  to  add  more  vertices  to  the  object  than  you  originally  allocated,  undesireable 
effects  may  occur.  NumPolygon  is  the  total  number  of  polygons  that  make  up  the  object. 
*NAME  is  a  pointer  to  the  name  for  this  object.  This  function  is  used  in  the  following  manner: 

OBJECT  *anobject; 

anobject  =  newobj  (  0,  8,  6,  "An  Object"  ); 

Once  we  allocate  the  space  for  an  object,  we  need  to  give  it  the  vertices  that  make  up  the 
object.  Vertices  are  added  using  the  function  add_vertex.  The  format  of  this  function  is 

addvertex  (  OBJECT  *OBJ,  long  X,  long  Y,  long  Z  ) 

OBJ  is  a  pointer  to  the  object  that  we  add  the  vertex  to.  X,  Y,  and  Z  are  the  object 
coordinates  for  the  vertex.  The  following  adds  eight  vertices  to  the  object  allocated  above. 

add  vertex  (  anobject,  0,  0,  0  ); 
add  vertex  (  anobject,  0,  0,  10  ); 
add  vertex  (  anobject,  0,  10,  0  ); 
add  vertex  (  anobject,  0,  10,  10  ); 
add  vertex  (  anobject,  10,  0,  0  ); 
add  vertex  (  anobject,  10,  0,  10  ); 
add  vertex  (  anobject,  10,  10,  0  ); 
add  vertex  (  anobject,  10,  10,  10  ); 
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It  is  important  to  remember  the  order  that  the  vertices  are  given  to  the  object  The  first 
vertex  is  numbered  0  and  in  our  case,  the  last  is  number  7.  The  next  step  is  to  tell  the  object 
about  the  polygons  that  make  up  the  structure  of  the  object.  This  is  done  with  the  add  poly 
function  call  This  function  is: 

POLY  *add_poly  (  OBJECT  *OBJ,  unsigned  color,  int  Vertnum  ); 

This  function  has  as  parameters,  the  pointer  of  the  object  the  polygon  is  being  added  the 
desired  color  of  the  polygon  and  the  total  number  of  points  in  the  polygon.  In  return  we  receive  a 
pointer  to  the  polygon.  For  the  above  example,  let's  add  six  polygons.  If  you  haven't  guessed 
this  creates  a  box. 

POLY  *sidel,  *side2,  *side3,  *side4,  *side5,  *side6; 

sidel  =  add  poly  (  anobject,  1,  4  ); 
side2  =  addpoly  (  anobject,  1,  4  ); 
side3  =  add  poly  (  anobject,  1,  4  ); 
side4  -  addpoly  (  anobject,  1,  4  ); 
side5  =  add  poly  (  anobject,  1,  4  ); 
side6  =  add  poly  (  anobject,  1,  4  ); 

At  this  point,  our  object  has  eight  vertices  and  six  polygons.  The  object  holds  the  exact 
positions  of  the  vertices,  but  the  polygons  cannot  be  built  because  we  have  not  given  the  object 
the  locations  for  the  polygons.  Polygons  are  built  from  the  vertices  that  we  gave  the  object 
previously.  When  specifying  polygons,  we  specify  the  points  in  clockwise  order  when  viewing  the 
polygon  from  the  outside  of  the  object.  This  is  a  simple  task  for  our  box  but  can  be  exhaustive  for 
a  detailed  object. 

We  will  add  the  points  for  the  top  and  bottom  sides.  Points  are  added  to  polygons  using 
the  function  add_point.  This  function  is  defined  as: 

add_point  (  OBJECT  *OBJ,  POLY  *P,  int  vertex  ); 

OBJ  is  the  object  that  we  add  the  polygon  point  to.  P  is  the  poly  to  add  the  point 
Vertex  is  the  number  of  the  vertex  to  add  to  the  polygon.  To  create  the  top  side  to  our  box 
assume  that  the  bottom  left  front  point  of  our  cube  is  at  the  origin,  we  use  the  statements:  ' 

add  point  (  anobject,  sidel,  3  ); 
add  point  (  anobject,  sidel,  7  ); 
add  point  (  anobject,  sidel,  6  ); 
add  point  (  anobject,  sidel,  2  ); 

For  the  bottom  of  the  box: 
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add 
add 
add 
add 


point  (  anobject,  sidel,  0  ); 
point  (  anobject,  sidel,  4  ); 
point  (  anobject,  sidel,  5  ); 
point  (  anobject,  sidel,  1  ); 


We  continue  this  for  the  remaining  sides.  As  I  wrote  this  article,  I  sketched  the  box  on 
paper  and  put  a  number  beside  the  vertices  according  to  the  way  I  passed  them  to  the  object  in  the 
calls  above.  This  makes  the  job  of  creating  objects  much  easier. 

It  should  be  obvious  that  complex  objects  are  more  complicated  and  time  consuming  to 
create.  We  desparately  need  a  modelling  program  in  which  we  interactively  create  objects  and  the 
program  generates  the  calls  for  us. 

The  next  step  allows  Rend386  to  do  internal  calculations  for  the  object.  This  is  performed 
using  the  compute_obj  function.  The  format  of  this  function  is: 


For  our  object,  we  execute 

compute  obj  (  anobject ); 

The  Rend386  documentation  states  that  this  function  computes  polygon  normals,  the 
bounding  sphere,  and  other  things.  Once  this  function  has  executed,  we  are  ready  to  render  the 
object. 

Object  Lists 

Before  we  can  render  the  object,  we  have  to  change  into  a  form  that  the  Tenderer  accepts. 
This  form  is  called  an  object  list.  An  object  list  is  a  linked  list  of  objects  that  is  pasted  to  the 
Tenderer.  The  Tenderer  moves  down  the  list  and  render  each  of  the  objects.  It  should  be  noted 
that  a  program  can  have  as  many  object  lists  as  necessary.  For  instance,  if  a  program  modeled  a 
building,  each  room  of  the  building  could  be  an  object  list. 

First,  we  must  obtain  an  object  list  from  the  system.  We  use  the  function  new_obj!ist. 
The  form  of  this  function  is: 


There  are  no  parameters  for  this  function.  Once  executed,  it  returns  a  pointer  to  a  usable 
object  list.  We  obtain  an  object  list  with  the  statements: 


compute_obj  (  OBJECT  *OBJ  ); 


OBJLIST  *new  objlistQ; 


OBJLIST  *ourlist; 


ourlist  =  new_objlist(); 
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We  now  add  objects  to  the  new  objlist.  Remember  that  Tenderer  renders  the  objects  in  the 
order  that  they  are  put  on  the  list.  So  if  a  particular  object  needs  to  be  rendered  first,  place  it  on 
the  list  first.  Objects  are  added  with  the  function  addtoobjlist  This  function  is: 

add_to_obj!ist  (  OBJLIST  *LIST,  OBJECT  *OBJ  ); 

*LIST  is  a  pointer  to  the  object  list  we  are  adding  the  object.  *OBJ  is  a  pointer  to  the 
object  we  are  adding.  To  add  our  object  we  execute: 

add_to_objlist  (  ourlist,  anobject ); 

We  are  ready  to  render  the  object.  This  is  performed  with  the  function  render.  The 
function  is: 


render  (  OBJLIST  *objlist,  VIEW  *view  ); 

*OBJLIST  is  the  objlist  we  want  to  have  rendered.  *VIEW  is  the  view  used  when 
rendering  the  given  object  list.  Refer  to  the  previous  article  for  an  explanation  on  the  skeleton  for 
Rend386  programs. 

Object  Manipulations 

Once  the  object  displayes  on  the  computer  screen,  we  are  finished.  However  there  are 
times  when  we  want  to  move  the  object.  If  you  have  used  the  segment  feature  of  Rend386  you 
know  that  manipulating  segments  is  very  easy.  You  may  have  noticed  that  there  are  no  direct 
ways  to  create  segments  as  there  is  to  crate  objects.  Segments  are  created  from  FIG  files  To 
manipulate  objects,  we  must  return  to  the  basics  of  computer  graphics  and  the  matrix. 

Objects  and  Matrices 

The  original  design  for  objects  in  Rend386  was  for  objects  to  be  completely  static  The 
eyepomt  moved  about  them  not  the  other  way  around.  The  second  version  of  Rend386  included 
the  matrix  functions  necessary  for  the  object  to  move.   We  use  these  functions  to  rotate  scale 
and  translate  our  objects.  In  addition,  we  are  able  to  rotate  about  a  point  and  an  axis. 

Matrix 

In  Rend386,  matrices  are  created  using  the  make_matrix  function.  This  function  is 
defined  as: 


make_matrix  (  MATRIX  m,  long  rotX,  long  rotY,  long  rotZ,  long  TransX,  long  TransY, 
long  TransZ  ); 

This  function  takes  the  information  provided  and  fills  in  the  appropriate  locations  of  the 
matrix  M.  RotX,  rotY,  and  rotZ  are  rotation  values  around  the  specified  axes.  These  values  are 
m  16. 16  format  or  a  sixteen  bit  integer  part  and  a  sixteen  bit  fraction  part.  Normally  we  work 
with  angles  in  a  degree  format.  To  convert  from  a  degree  to  a  16. 16  format,  multiply  the  degree 
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value  by  65536L.  TransX,  transY,  and  transZ  are  translation  values  in  32-bit  format.  These 
values  are  taken  to  be  world  coordinate  value. 

The  matrix  created  is  4  by  3  of  long  integers.  The  3  by  3  part  of  the  matrix  is  used  for 
rotation  and  scaling  and  the  1  by  3  bottom  part  of  the  matrix  is  for  translations.  Note  that  there  is 
no  direct  way  to  scale  the  image  given  the  matrix  function  above.  We  must  create  this  matrix 
using  several  other  functions. 

Translation 

Translation  is  simply  a  graphics  term  for  moving  the  object.  We  translate  the  object  from 
its  current  position  to  another  position  by  either  adding  or  subtracting  some  value  from  the 
current  location  of  the  object.  The  first  step  in  the  translation  process  is  to  obtain  the  memory  for 
a  matrix.  This  is  done  with  the  statement: 

MATRIX  mat; 

Notice  that  we  do  not  obtain  the  pointer  to  a  MATRIX  type  but  a  variable  of  type 
MATRIX.  After  this,  we  make  the  matrix  using  the  translation  values  we  want  to  use.  To 
accomplish  this  we  use  the  make_matrix  function  detailed  above.  Let's  do  two  translations.  The 
first  translates  our  box  fifty  steps  to  the  left.  The  coordinate  system  in  Rend386  increases  in 
positive  values  from  the  left  to  the  right  on  the  x  axis.  So  we  want  to  translate  the  box  -50  steps. 
The  function  call  to  create  our  matrix  is: 

make_matrix  (  mat,  0,  0,  0,  -50,  0,  0  ); 

Now  that  we  have  our  matrix,  we  must  apply  it  to  the  object  or  objects  that  we  want  to 
translate.  We  use  the  apply_matrix  function  to  do  this.  The  function  is  defined  as: 

apply_matrix  (  OBJECT  *obj,  MATRIX  m  ); 

For  our  example  the  function  call  is: 

applymatrix  (  anobject,  mat ); 

This  function  takes  the  values  in  the  given  matrix  and  applies  the  values  to  the  object's 
vertices.  This  application  does  not  permanently  change  the  position  of  the  object.  When  the 
object  is  rendered,  the  original  coordinates  of  the  vertices  are  tranformed  with  the  values  from  the 
application  of  the  matrix.  This  is  a  one  shot  deal.  Any  further  translations  are  from  the  original 
position  of  the  object.  Let's  translate  the  object  -25  steps  in  the  Y  direction  and  50  in  the  X 
direction.  The  statements  would  be: 

makematrix  (  mat,  0,  0,  0,  50,  -25,  0  ); 
apply_niatrix  (  anobject,  mat ); 
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If  we  apply  the  above  statements  after  applying  the  first  translation,  the  object  moves  back 
to  its  original  position,  then  50  steps  in  the  X  direction,  and  moves  down  by  25  steps  for  the  -25 
steps  in  the  Y  direction. 

If  we  want  the  translations  to  stick,  we  must  somehow  combine  the  previous  translation 
matrix  with  the  new  matrix.  This  is  accomplished  by  multipling  the  matrices  to  each  other  to 
create  a  new  matrix.  Rend386  provides  part  of  the  solution  in  the  matrix  mult  function  This 
function  is: 

matrix  mult  (  MATRIX  a,  MATRIX  b,  MATRIX  c  ); 

It  performs  a  multiplication  of  the  top  3  by  3  part  of  matrix  a  to  matrix  b  and  puts  the  result  in 

matrix  c.  This  takes  care  of  the  rotational  part  of  the  matrices.  For  the  translation  part  we  must 
do  three  additions:  ' 

c[3][0]  =  aI3J[0]  +  b[3][0J; 
c[3][l]  =  a[31[l]  +  b[3][ll; 
c[3][2]  =  a[3][2]  +  b[3][2]; 

These  additions  combine  the  translations  into  the  proper  form.  For  example  if  you  take 
the  two  translations  above: 

makematrix  (  mat,  0,  0,  0,  -50,  0,  0  ); 
and  make_matrix  (  mat,  0,  0,  0,  50,  -25,  0  ); 

perform  the  matrix  multiplication  and  the  additions,  we  get  the  same  matrix  as  that  created  from 
the  statement: 

make_matrix  (  mat,  0,  0,  0,  0,  -25,  0  ); 

Clearly,  we  want  to  do  the  single  statement  above  instead  of  the  multiplication  and 
additions.  The  times  that  we  do  not  know  the  translations  coming,  the  sequence  above  gives  us 
the  ability  to  keep  a  running  translation  for  any  object. 

Rotation  about  an  axes 

There  are  two  types  of  rotation:  about  a  coordinate  axis  and  about  a  point   We  first  look 
at  a  rotation  about  a  coordinate  axis.  In  this  issue  of  PCVR,  the  Graphics  column  gives  a  full 
explanation  of  rotation  about  an  axis  and  I  refer  you  to  there  for  more  detailed  information 

The  first  rotation  is  performed  using  the  same  make_matrix  function  described  for  the 
translation  except  the  parameters  are  different.  We  begin  by  performing  a  rotaton  about  the  Z 
axis.  We  rotate  our  box  a  positive  45  degrees.  The  function  called  to  create  the  matrix  is: 

make_matrix  (  mat,  0,  0,  45*65536L,  0,  0,  0  ); 
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Recall  that  the  degrees  are  in  16. 16  format  and  need  to  be  converted  using  the 
multiplication  by  65536L.  This  matrix  is  applied  to  the  object: 

apply_object  (  anobject,  mat ); 

and  rendered. 

The  box  rotates.  Each  of  the  other  axis  rotations  are  the  same  except  the  parameters  are 
put  in  a  different  position.  The  make_matrix  function  call  allows  for  rotations  to  occur  in  all 
three  coordinate  axes  at  the  same  time  as  well  as  adding  a  translation.  This  provides  for  faster 
drawing. 

Rotation  about  a  point 

Rotation  about  a  point  is  similar  to  rotation  about  an  axis  except  that  we  add  two 
translations.  A  full  explanation  of  this  type  of  rotation  appears  in  the  next  issue  of  PCVR  in  the 
Graphics  column.  Basically,  we  need  to  translate  our  object  to  the  origin,  perform  the  rotation 
and  translate  back  to  the  desired  point.  As  an  example,  we  will  do  a  45  degree  rotation  about  the 
z  axis  and  the  point  10,10,10.  We  keep  track  of  the  manipulations  in  a  running  matrix.  First  we 
declare  our  matrices: 

MATRIX  temp_mat,  temp  mat2,  run  mat; 

Now  we  need  to  create  the  rotation/translation  to  the  origin  matrix.  Let's  assume  that  the 
object  is  at  the  location  50,0,0. 

makematrix  ( temp  mat,  0,  0,  45*65536L,  -50,  0,  0  ); 

Next  we  create  the  matrix  for  the  translation  to  10,  10,  10. 

make_matrix  ( temp  mat2,  0,  0,  0,  10,  10,  10  ); 

Since  these  matrices  need  to  be  performed  one  after  the  other,  we  combine  them  with: 

matrixmult  ( tempmat,  temp_mat2,  run  mat  ); 
run_mat[3]I01  =  temp_mat[31[0]  +  temp_mat2[3][0]; 
run_mat|3][l|  =  temp_mat[3][l]  +  temp_mat2[31|l|; 
run_mat|3|[2]  =  temp_mat[31[21  +  temp_mat2[3][2]; 

and  apply  the  matrix: 

apply_matrix  (  anobject,  run_mat ); 

and  render. 
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There  are  shortcuts  that  can  be  taken  when  you  know  the  exact  values  you  are  using  for 
the  rotation  and  translations.  The  above  example  did  not  need  all  three  matrices.  We  could  have 
done  the  calculations  in  a  single  matrix  but  we  may  not  always  know  the  exact  values  it  use. 

Scaling 

Scaling  an  object  can  be  performed  with  three  simple  multiplications  in  the  current 
manipulation  matrix.  The  value  at  location  [0][0]  controls  the  X  size,  the  value  at  location  [1][1] 
controls  the  Y  size,  and  the  value  at  location  [3][3]  controls  the  Z  size.  To  increase  the  size  of  an 
object  in  the  X  direction,  multiply  the  current  value  in  [0][0]  by  the  desired  scaling  size.  To 
increase  by  2  we  would  perform  the  following: 

run_mat[0][01  =  run_mat|0][0]  *  2; 

The  same  type  of  multiplication  increases  the  size  of  the  object  for  the  other  dimensions 
depending  on  the  matrix  location  used. 

Miscellaneous  Matrix  Functions 

In  this  section  I  want  to  point  out  several  matrix  functions  that  are  in  the  library  and  may 
be  useful  at  some  point.  The  first  is  identity.  This  function  takes  the  matrix  argument,  clears  it, 
and  places  I's  in  the  diagonal  positions.  When  this  matrix  is  applied  to  an  object,  the  object 
renders  in  the  same  position  as  it  was  before  the  translation.  The  function  is  defined  as: 

identity  (  MATRIX  mat ); 

The  function  matrixcopy  and  matrix  rot  copy  copy  one  matrix  to  another.  The  first 
function  copies  the  entire  4  by  3  matrix.  The  second  copies  the  3  by  3  matrix  and  zeros  the  last 
row.  These  functions  are  defined  as: 

matrix  copy  (  MATRIX  a,  MATRIX  b  ); 
matrix_rot_copy  (  MATRIX  a,  MATRIX  b  ); 


Miscellaneous  Object  Manipulations 

Listed  below  are  several  object  manipulation  functions  which  may  be  useful 

set_poly_color  (  OBJECT  *obj,  INT  polynumber,  UNSIGNED  color  );  -  This 
function  sets  the  given  polygon  of  the  specified  object  to  the  chosen  color 

OBJECT  *copy_obj  (  OBJECT  *obj,  INT  nverts,  INT  npolys,  CHAR  *name  );  - 

This  function  is  used  to  copy  an  existing  object,  *obj,  to  a  new  object  returned  by  the  function. 
This  function  allows  additional  vertices  and  polygons  to  be  added  if  needed 

highlight  obj  (  OBJECT  *obj  );  -  Sets  the  highlight  bit  on  the  colors  of  all  polygons  in 
the  object. 
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unhighlight_obj  (  OBJECT  *obj  );  -  This  is  the  reverse  of  the  function  just  mentioned. 

OBJLIST  Information 

There  are  several  functions  that  return  information  about  an  object  list.  These  functions 
are  generally  used  to  traverse  a  linked  list  of  object  in  the  object  list. 

OBJECT  *first_in_objIist  (  OBJECT  **list );  -  This  function  returns  the  first  object  in 
the  object  list  list.  To  traverse  the  object  list,  you  need  to  keep  the  pointer  that  this  function 
returns. 

OBJECT  *next_in_objlist  (  OBJECT  **!ist,  OBJECT  *obj  );  -  This  function  takes  the 
given  object  list  list,  locates  the  object  given  by  obj,  and  returns  the  next  object  after  it. 

OBJECT  *prev_in_objlist  (  OBJECT  **list,  OBJECT  *obj  );  -  This  function  does 
essentially  the  same  thing  as  next_in_objIist  except  it  returns  the  previous  object. 


Finishing  Up 

Once  we  have  created  our  objects,  object  lists  and  manipulated  them,  we  need  to  release 
the  memory  they  are  using.  Let's  first  get  rid  of  our  objects.  The  function 
delete_obj  (  OBJECT  *obj  )  takes  the  given  object  and  releases  the  polygon  information 
including  associated  vertices.  There  does  not  appear  to  be  any  way  of  removing  specific  vertices 
or  polygons. 

After  all  objects  have  been  deleted,  we  can  get  rid  of  our  object  lists.  The  function 
del_objlist  (  OBJLIST  *list );  removes  the  memory  associated  with  this  object  list.  One 
function  that  can  be  useful  is  remote Jrom  _objlist  (  OBJLIST  *list,  OBJECT  *obj  );  This 
function  removes  the  given  object  from  the  given  object  list.  Essentially,  we  are  doing  a'linked  list 
delete  operaton. 


PLG  Files 

The  PLG  file  accpets  an  object  from  the  user  in  a  convenient  way  Rend386  includes 
several  functions  for  reading  these  files.  The  function  load_plg  loads  a  pig  file  The  function  is 
defined  as: 

OBJECT  *load_plg  (  FILE  *input  ); 

The  file  descriptor  *input  is  assumed  to  be  a  valid,  open,  file.  This  function  reads  the  file 
with  the  current  translation  and  scaling  functions,  and  it  returns  a  pointer  to  the  newly  created 
object  If  the  pointer  returned  is  NULL,  then  there  was  a  problem  loading  the  figure  file  The 
current  translation  and  scaling  values  can  be  set  with  the  following  functions: 

setjoadplg^oflset  ( long  X,  long  Y,  long  Z  ); 
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This  fijncton  sets  the  current  offset  of  the  object  to  be  loaded. 

set  loadplg_scale  ( float  X,  float  Y,  float  Z  ); 

This  function  sets  the  current  scaling  factors  for  the  object  to  be  loaded.  An  object 
created  by  software  can  also  be  saved  to  a  pig  file  using  the  function  save_plg.  This  function  is: 

save_plg  (  OBJECT  *obj,  FILE  *output ); 

Again,  the  file  *output  is  assumed  to  be  opened.  PLG  files  are  the  easiest  way  to  create 
an  object  in  your  program.  The  functions  above  are  used  in  the  following  format: 

First  open  the  file: 

in  =  fopen(  "The  object  file",  "r") 

Set  the  offsets  and  scaling  factors: 
set_loadplg^offset(0,0,0); 

set_loadplg_scale(l,l»l); 

Load  the  file: 

theobject  =  load_plg(in) 

Close  the  file: 

fclose  (  in  ); 

Before  adding  the  loaded  object  to  an  object  list,  its  a  good  idea  to  check  the  pointer  and 
make  sure  that  it  is  not  NULL. 

Program 

There  are  various  information  and  manipulation  functions  in  the  library  that  we  have  not 
covered.  I  suggest  reading  the  documentation  and  using  this  issue  of  PCVR  as  a  supplement. 
The  demonstrate  program  shows  the  object  creation,  manipulation,  and  deletion  topics  that  we 
have  covered  above.  Check  the  program  comments  for  details  on  the  keys  necessary  for 
operating  the  demo.  The  program  is  called  object.c 
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Rend386  and  Figures 


Segments  are  a  step  beyond  objects.  From  the  Rend386  documentation,  "A  segment  is  i 
piece  of  articulated  (  multi-jointed  )  figure.  Each  segment  has  a  parent  segment;  the  parent  [of] 
the  *'root"  segment  is  NULL.  Each  segment  has  a  linked  list  of  children,  and  each  segment  has  z 
'sibling'  which  is  the  next  segment  in  the  parent's  linked  list  of  children."  An  example  of  a  set  of 
segments  is: 


Head 


The  three  segments,  HEAD,  BODY,  and  ARM, 
makeup  a  figure.  The  HEAD  segment  is  the  root  of  the 
figure.  It's  one  child  is  BODY.  BODY  has  no  sibling 
but  has  a  single  child,  ARM.  ARM  has  no  sibling  or 
children.  Each  segment  has  a  set  of  parameters 
associated  with  it. 


*  Name 

*  Position 

*  Rotation 

*  Segment  Number 

*  PLG  file 

*  Scale  of  object  in  PLG  file 

*  Shift  of  object  in  PLG  file 

*  Sort  type 

*  Color  Mapping 


FLG  Files 

The  simplest  way  to  create  segments  and  figures  is  to  use  a  FLG  file.  This  file  is  a 
collection  of  segment  descriptions  Either  one  segment  or  a  series  of  segments  can  create  a 
figure.  The  format  of  a  figure  file  is  given  in  the  Rend386  documentation  and  will  not  be  repeated 
here.  Before  continuing  with  this  article,  I  suggest  becoming  familiar  with  the  format  of  figure 
files  to  give  yourself  a  little  background  information.  To  accept  a  figure  file  in  your  program,  you 
will  need  code  similar  to: 
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OBJLIST  *OURLIST; 

SEGMENT    *NEW_SEGMENT,  *readseg(); 


set_readseg_objlist  (  OURLIST  ); 

NEW  SEGMENT  =  readseg  ( infile,  NULL  ); 

update_segment  ( NEW  SEGMENT ); 

This  is  the  basic  code  necessary  to  read  a  figure  file.  We  begin  by  creating  an  object  list 
which  holds  the  new  segment,  since  the  Tenderer  requires  an  object  list.  The  function 
set_readseg_objIist  tells  the  system  software  that  we  are  going  to  read  a  segment  file  and  to 
attach  all  segments  to  the  object  list  given  as  the  parameter.  Next,  we  read  the  input  file.  The 
function  readseg  reads  the  segments  from  the  previously  opened  file  infile  and  puts  them  on  the 
object  list.  The  second  parameter  of  this  function  is  the  parent  of  the  new  segments  in  the  file.  In 
this  case,  the  specified  parent  is  null  and  the  first  segment  is  the  parent  segment.  If  there  is  an 
error  during  readseg,  it  returns  NULL.  It  is  a  good  idea  to  check  for  this  condition.  The  last  step 
is  to  update  the  new  segment(s)  using  the  function  update_segment.  This  function  recomputes 
internal  representation  information. 

As  we  mentioned  earlier,  this  is  the  minimalist  code  necessary  for  reading  figure  files.  It 
does  not  take  advantage  of  some  of  the  features  of  segments.  One  such  feature  is  segment 
numbers.  To  take  advantage  of  this  feature,  we  have  to  do  a  little  more  work. 

Segment  Numbers 

During  the  figure  file  definition,  each  segment  has  a  possible  segment  number.  These 
segment  numbers  are  indices  into  an  array  of  segments.  Anytime  we  want  to  manipulate  a  specific 
segment,  we  use  this  number.  The  first  step  is  to  setup  the  array.  There  must  be  enough 
locations  in  the  array  to  handle  any  segment  number  you  put  in  the  figure  file.  If  you  have 
numbers  from  1  to  8,  there  must  be  a  location  8  in  the  array  definition.  The  array  is  defined  as 

SEGMENT  *segment_arrayIHighest  number  +  1] 

The  system  automatically  initializes  this  array  if  we  tell  it  too.  We  do  this  using  the 
function  set_readseg_seglist.  This  function  takes  as  parameters,  the  name  of  the  array  we  just 
declared  and  the  total  locations  in  this  array.  It  should  be  noted  that  if  you  are  using  the  segment 
numbers,  you  have  a  different  array  for  each  figure.  There  can  be  as  many  segment  arrays  as  there 
are  figures.  If  our  highest  number  was  12,  then  our  function  call  would  be: 

set  readseg  seglist  ( segmentarray,  13  ); 

This  function  is  located  in  the  vicinity  of  the  function  setreadseg ohjlisl   Once  the 
figure  has  been  read  in  by  the  system,  we  can  access  any  segment  using  this  array. 

Full  Code 

The  code  for  reading  figure  files  including  error  detection  would  appear  as 
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OBJLIST  "ourlist; 

SEGMENT    *new_segment,  *segment_array[xj,  *readseg(); 

set_readseg^objlist  (  ourlist ); 

set_readseg_seglist  (  segment  array,  x  ); 

if  (  (  new  segment  =  readseg  (  infile,  NULL  ))  ==  NULL  )  { 

printf("Bad  File\n"); 

exit(l); 

} 

else 

updatesegment  (  new_segment ); 


Translation 

Now  that  we  have  our  segments,  we  need  to  manipulate  them.  The  idea  behind  figures 
and  segments  is  to  represent  the  real-world.  Movement  applied  to  the  root  segment  of  a  figure 
should  affect  the  children  segments  as  well.  Move  the  root  to  a  new  location  and  all  of  the 
children  should  follow.  The  same  is  true  for  other  segments  in  the  figure.  Actions  performed  to  a 
segment  will  affect  its  children  and  their  children.  The  best  way  to  experience  this  is  to  try  the 
demo  program  on  the  BODY.FIG  file.  Manipulate  the  different  parts  of  the  robot  and  see  how 
the  segments  work  together. 

The  library  includes  two  different  types  of  translation  functions  for  segments.  These  are 
rel_move_segment  and  abs_move_segment  The  function  reI_move_segment  is 

rel_move_segment  (  SEGMENT  -segment,  long  X,  long  Y,  long  Z  ); 

This  function  moves  the  segment  -segment  (  and  all  children  ),  by  the  values  given  in  X, 
Y,  and  Z.  The  move  is  relative  to  the  current  position.  For  example,  If  a  figure  is  located  at 
1 0, 1 0, 1 0  and  we  have  the  function 

rel_move_segment  (  figure,  20,  25,  45  ); 

the  figure  is  now  located  at  position  30,  35,  55.  We  simply  add  the  values  in  the  function  call  to 
the  current  position  of  the  figure.  In  contrast  to  this  function  is  the  function  abs  move  segment 
This  function  is:  ~  ~ 

abs_move_segment  (  SEGMENT  -segment,  long  X,  long  Y,  long  Z  ); 

This  function  moves  the  segment  -segment  (  and  all  children  ),  to  the  position  given  by 
the  values  in  X,  Y,  and  Z.  The  move  is  absolute.  For  example,  a  figure  located  at  1 0, 1 0, 1 0  and 
has  the  function  call 

abs  mov  segment  (  figure,  20,  25,  45  ); 
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The  figure  moves  to  the  position  20,  25,  45.  The  previous  values  for  the  location  of  the 
segment  and  its  children  are  replaced  by  the  values  in  the  function.  This  is  not  the  only  call  we 
need  to  make.  Once  the  move  functions  have  executed,  we  tell  the  system  software  to  update  the 
current  segment  and  its  children.  This  is  done  with  the  updatesegment  function  call  we 
discussed  earlier.  Once  this  update  is  made,  the  figure  moves  on  to  the  next  rendering. 

Rotation 

Rotation  is  similiar  to  translations.  The  library  gives  us  two  functions  rel_rot_segment 
and  absrotsegment  The  relrotsegment  is: 

rel_rot_segment  (  SEGMENT  "segment,  long  RX,  long  RY,  long  RZ  ); 

This  function  rotates  the  given  segment  "segment  BY  the  values  RX,  RY,  and  RZ. 
These  values  are  in  the  familiar  16.16  format.  Degree  angles  must  be  multiplied  by  65536L  before 
used.  As  demonstrated  in  the  translation  function  above,  the  values  given  in  the  function  are 
added  to  the  current  rotational  values  of  the  given  segment  and  its  children.  The  library  provides 
us  with  an  absolute  rotation  in  the  function  absrot_segment. 

abs  rot  segment  (  SEGMENT  "segment,  long  RX,  long  RY,  long  RZ  ); 

This  function  rotates  the  given  segment  TO  the  angle  positions  given  in  the  RX,  RY,  and 
RZ  parameters.  Each  of  these  functions  must  be  followed  by  the  update_segment  function. 

Identification 

We  have  already  seen  one  way  to  identify  individual  segments.  This  used  the  segment 
array  once  the  figure  file  is  read.  Rend386  gives  us  several  other  identification  routines.  These 
are:  seggetname,  seg^setname,  find  root_segment,  parent  segment,  child  segment, 
sibling  segment,  find_segment_by_name 

The  first  two  functions  and  the  last  one  deal  with  the  name  of  a  segment.  When  the  figure 
is  defined  in  the  FIG  file,  each  segment  is  given  a  name.  These  names  are  used  to  identify 
individual  segments.  You  may  be  wondering  if  we  can  use  segments  by  name,  why  do  we  need 
the  segment  numbering  array  detailed  above?  The  answer  is  that  each  time  we  want  to  use  a 
segment,  we  have  to  ask  the  system  to  search  using  its  name  and  the  function 
find_segment_by_name.  This  function  takes  a  name  and  searches  a  segment  list  for  a  match 
This  is  a  linear  search.  Linear  searches  are  not  practical  in  graphics  programming.  However, 
there  may  be  situation's  where  the  time  element  is  not  an  issue.  The  function 
findsegmentbyname  is: 

SEGMENT  "find  segment  by  name  (  SEGMENT  "seg,  char  "name  ); 

This  function  takes  the  name  given  and  searches  from  the  given  segment  looking  for  a 
match.  If  a  match  is  successful,  a  pointer  returns  to  the  segment,  otherwise  NULL  is  returned. 
The  two  other  functions  are  used  to  set/receive  segment  names   Seg_setname  is 
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SEGMENT  ^parent  segment  (  SEGMENT  "segment ); 
The  function  child  segment  returns  the  child  of  the  given  segment: 

SEGMENT  *child_segment  (  SEGMENT  'segment  ); 
The  function  sibling  segment  returns  the  sibling  of  the  current  segment: 

SEGMENT  *sibling_segment  (  SEGMENT  "segment ); 

In  the  version  2.01  of  Rend386,  these  functions  were  used  to  locate  specific  segments  in  a 
figure.  The  Virtual  Hand  program  in  Issue  3  of  PCVR  sets  up  artificial  pointers  to  the  hand 
segments.  These  functions  allow  me  to  associate  a  pointer  for  every  digit  in  the  hand.  The 
segment  numbering  array  in  the  new  version  of  Rend386  makes  use  of  these  functions  obsolete. 

Limits 

Segments  can  be  given  limits  when  defined.  These  limits  are  relative  to  the  segment's 
parent.  Limits  can  be  defined  in  two  ways.  The  first  is  during  definition  in  the  FIG  file.  The 
second  is  using  the  function  sct__seg_Umits.  This  function  is  defined  as: 

4,.n«i£He(>  vises',  ''U-.r;V  /  .'T^MFNT  *sqv:in?nt,  ■       ^ans?*^| ::      urif-i^niT*  M><;': "  • 

I  l'<;s  lUIiCt  iO •iiiO?^\,l  '-hi'  i'Tilis ;-.  ,v  v't  •-,  j<1  ii;f  ;\i !  ;-i  y  -r:-     i..'  >\V.''i£'-i'   '  =.PV'^,'I-/i  '"'?f* 

l:  \Uci:  vaiiiC-'  ! ;h.-ii'igttd  i'-'i  t!K  Sti/.tt  i'.1  " ;  >.*-iil>'<  K  i^O^H^  by  :ht.  ;"!et  jVsA.VK      The  <;•; 

treated  by  ORing  the  following  'j'vtines"  declared  m  the  Rend386.h  file. 


#dcfine  LIMJV1INTX  0x0001 
#define  LIMMAXTX  0x0002 
ftdefine  LIM  MINTY  0x0004 
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tfdefine  LIM 

MAXTY 

0x0008 

tfdefine  LIM~ 

MINTZ 

0x0010 

#define  LIM 

MAXTZ 

0x0020 

#define  LIM~ 

MINRX 

0x0040 

#define  LIM] 

MAXRX 

0x0080 

#define  LIM 

[minry 

0x0100 

^define  LIM 

MAXRY 

0x0200 

#define  LIM 

MINRZ 

0x0400 

#define  LIM~ 

MAXRZ 

0x0800 

If  we  update  the  minimum  and  maximum  X  translation  values,  we  use  a  mask  of  0x003. 
This  function  also  returns  a  bitmask  indicating  which  of  the  limits  are  valid  or  not.  We  can  also 
retrieve  the  limits  for  a  segment  using  the  function  get_seg^limits.  This  function  is: 

unsigned  get  seg  limits  (  SEGMENT  "segment,  long  limits[12]  ); 

This  function  returns  the  limit  values  in  the  array  limits  and  a  bitmask  indicating  which  of 
the  limits  are  valid.  The  question  to  be  asked  is,  how  do  we  use  these  limits?  Let's  look  at  an 
example. 

If  you  have  a  robot  figure  and  you  set  the  maximum  X  limit  of  an  arm  to  50,  this  indicates 
that  the  arm  is  not  allowed  to  move  more  than  50  places  in  the  positive  direction  from  its  parent. 
If  you  try  a  translation  that  is  greater  than  50,  the  renderer  limits  the  segment  to  50.  The  system 
does  all  of  the  checking  for  use  and  we  do  not  have  to  do  a  thing. 

Delete 

After  a  program  is  finishes,  the  figures  must  be  removed.  The  function  delete_segment 
removes  the  segment  and  frees  any  memory  associated  with  the  segment.  The  format  of  the 
function  is: 

delete_segment  (  SEGMENT  "segment,  void  (  "function  )  () ); 

In  most  cases,  the  function  has  the  form 

delete_segment  (  SEGMENT  "segment,  NULL  ); 

Program 

The  demonstration  program  called  fig.c  illustrates  some  of  the  concepts  discussed  above. 
The  instructions  for  the  program  are  given  in  the  comment  section  at  the  top  of  the  program. 
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Rend386  Sega/Powerglove  Interfaces 


In  the  third  Issue  of  PCVR,  we  discussed  a  pointer  package  for  using  the  Mattel 
Powerglove  with  version  2.01  of  Rend386.  Version  3.01  adds  both  Sega  3D  glasses  and  Mattel 
Powerglove  support  built  in. 

The  software  interfaces  for  the  Sega  and  Powerglove  are  interrupt  based.  Using  the 
function  init_SGJnterrupt,  you  indicate  which  of  the  interfaces  you  are  dealing  with  and  the 
number  of  times  to  poll  the  glove.  The  function  is: 

init_SG_interrupt  (  void  (*sega_function),  void  (*glove_f unction),  int  POLL  ); 

The  first  two  parameters  to  this  function  are  addresses  of  functions  to  call  for  each  of  the 
interfaces.  If  one  of  the  interfaces  is  not  being  used,  NULL  should  be  sent  to  the  function  By 
setting  up  the  function  in  this  fashion,  the  developers  of  Rend386  give  you  the  choice  of  using 
their  routines  or  another  routine  written  by  yourself  or  someone  else.  The  last  parameter  POLL 
is  the  time  interval  for  polling  the  glove.  According  to  the  Rend386  documentation  the  units  for' 
h.s  value  is  1  19  microseconds  and  they  recommend  a  value  of  6500  when  using  the  Seea 
interface.  b 

Before  we  can  begin  using  the  interfaces,  we  must  give  the  function  interface  routines 
Rend386  provides  a  function  for  each  of  the  interfaces. 

Sega 

The  function  switch_sega  performs  two  functions:  1)  switches  the  shutters  in  the  glasses 
using  both  the  interface  in  Issue  3  of  PCVR  and  the  text  file  distributed  with  Rend386  and  2) 
switches  the  graphics  display  screen.  The  Rend386  system  has  two  global  variables  called 
left  page  and  right_page.  These  variables  contain  the  page  number  to  use  during  the  switching 
of  the  graphics  screen.  One  of  the  convenient  features  of  using  the  320  x  200  x  256  display  mode 
is  four  pages  ava.lable  for  graphics  use.  We  initiate  a  system  of  using  two  display  modes  per  eye 
Borland  C  accomplishes  this  by  using  the  setactive  and  setvisual  functions.  One  of  the  pages  is 
the  active  page  and  one  is  the  visual  page.  Each  eye  has  a  set  of  these  pages.  The  code  to  do  this 
might  look  like:  (  the  left  eye  uses  pages  0  and  1,  the  right  eye  uses  pages  2  and  3  ); 

if  (  ++current_page  =  2  )  current_page  =  0; 

clear  display  (  currentpage  ); 
set  drawpage  (  currentpage  ); 
render  (  objlist,  &left_eye_view  ); 

clear  display  (  current_page+2  ); 
set_drawpage  ( current_page+2  ); 
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render  (  objlist,  &right_eye_view  ); 

lefteye  =  currentpage; 
right  eye  =  current  page  +  2; 

Let's  look  at  this  code  section.  This  code  is  located  in  the  new  display  function  Upon 
entrance,  we  mcrement  to  the  next  available  page.  Since  we  are  usingTwo  displays  per  eveTe 
check  to  make  sure  that  the  counter  variable  only  increments  to  1.  We  clear  the  current  dTs'Z 
page  let  the  system  know  to  draw  on  this  page,  and  render  the  left  eyes  view  of  theTcen  We" 
pe  tth.sforthenghteye.  Before  leaving,  we  se,  the  sega  global  variable  .eft  eye  and 

3  for  bright  eye.PPr0Pnate  ""^  ^  ^        PageS  °  and  1  f°r  the  left  ^  a"d         *  a"« 

to      .  ft  °rHer  fu       T  ^  HaVe  3  rea'  Se"Se  0f  dePth>  we  have  to  P««nt  the  correct  images 
to  the  left  and  nght  eye.  Rend386  gives  us  this  ability  using  stereoscopic  functions. 

Stereoscopic  Functions 

We  .en?"!  '!f  8  ^  ^  ^  ^  aboW  is  how  t0  create  the  ^  and  right  views? 

We  generate  these  v,ews  us.ng  the  function  make_Stereo  view.  This  function  takes  globaHtereo 
vew  parameters  and  the  current  view  which  creates  the  left  and  right  eye  views 

STEREO  rnn'tl     /  ,7^°         "  ^  stereoscoPic  vi^ing  parameters.  The  structure 

SSSST        parameters  The  fields  are  ( taken  from  the  Rend386 

phyS_scree„_dist  -  the  distance  in  mm  from  the  eye  to  the  screen 

phypcree„_w,dth  -  the  viewport  width  on  the  screen  in  mm 

p.xel_w.dth  .  the  viewport  width  in  pixels 

phyS_eye_spacing  -  the  physical  spacing  between  the  eyes,  in  mm 

phys_co„vergence  -  the  convergence  distance  in  mn,  („suaHy  the  same  as 

phys_screen_dist) 
world_scaling  .  worid  units  per  phvsjca,  mm 

The  Ren^fiT  ^  ^  ^  for  the  SeSa  3D  B^ses  and  our  eyes 

5*65536L    dem°nStratl0n  Pr°«ram  uses  the  folIowing  values:  700,  240  320,  55,  700,  and 

The  ic^of^^STit St£re0  P3rameterS'  ^  'eft  a"d  ^  — 

make_stereo_view  (  VIEW  .original,  VIEW  .„ew_view,  STEREO  'structu,  in,  whicheye  ); 

The  current  view  is  the  first  parameter  in  the  function.  The  function  takea  that  view 

parameter  new_view.  The  v,ew  g.ven  by  the  function  is  determined  by  the  last  parameter  If 
wh.cheye.s  1 ,  we  get  a  left  eye  view.  If  the  p..^  i,  2.  we  ge,  .  rii«  eye^ieT^ 
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documentation  shows  a  small  piece  of  code  for  the  use  of  this  function.  It  looks  something  like 
this: 

STEREO  stereo_params  =  {...}; 
VIEW      current  view  ={ };, 

Ieft_view  -  {  }; 

right  view  =  { }; 

compute_view_factors  (  &current_view  ); 

make_stereo_view  (  &current_view,  &left_view,  stereo_params,  1  ); 
render  (  objlist,  &left_view  ); 

make_stereo  view  (  &current_view,  &right_view,  stereoparams,  2  ); 
render  (  objlist,  &right_view  ); 

The  second  thing  we  do  is  setup  the  current  view.  We  generate  the  left  eye  view  and 
render  the  scene.  After  this,  we  generate  the  right  eye  view  and  render  the  scene  again.  Because 
most  VR  systems  have  the  view  change,  we  have  to  recompute  the  stereo  views  each  time. 
However,  by  using  some  simple  efficiency  techniques,  we  do  not  have  to  compute  the  left  and 
right  view  EVERY  time  we  redraw  the  scene.  Using  a  flag,  the  routine  that  changes  the  current 
view  of  the  user  can  set  the  flag  to  'true'  which  indicates  that  the  left  and  right  view  must  be 
recomputed.  If  the  flag  remains  false,  there  is  really  no  need  to  recompute  the  left  and  right  views 
since  the  original  view  did  not  change. 

Given  the  above  information,  we  can  fill  in  the  missing  information  in  the  redraw  code 
above:  (  leaving  efficiency  out  ) 

if  (  ++current_page  ==  2  )  currentpage  =  0; 

clear_display  (  current_page  ); 
setdrawpage  (  current_page  ); 

make_stereo_view  (  &current_view,  &left_eye_view,  &s_params,  1  ); 
render  (  objlist,  &left_eye_view  ); 

clear_display  (  current_page+2  ); 
set_drawpage  (  current_page+2  ); 

make_stereo_view  (  &current_view,  &right_eye_view,  &s  parnnis,  2  ); 
render  (  objlist,  &right_eye_view  ); 

leftpage  =  currentpage; 
rightpage  =  current_page  +  2; 

Using  the  switch_sega  function  and  the  above  routine,  the  system  displays  scenes  so  that 
users  wearing  the  Sega  3D  glasses  see  3D  objects.  When  the  system  is  shut  down,  the 
programmer  should  call  the  function  sega  off.  This  function  opens  the  shutters  on  the  glasses, 
keeping  them  from  any  damage. 
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PowerGlove  Interface 

Now  that  we  can  see  in  3D,  we  need  a  way  to  interact  in  3D.  We  do  this  using  the 
Powerglove.  We  have  already  mentioned  the  interrupt  function.  This  interrupt  function  requires 
another  function  as  well.  Rend386  provides  a  function  called  gIove_int_handler.  There  is  little 
information  about  this  function  in  the  documentation.  This  function,  once  activated,  requests 
information  from  the  glove  and  queues  it  until  a  read  is  performed  by  the  user.  Those  familiar 
with  the  Glove  code  from  the  first  issue  of  PCVR  and  available  on  the  net  will  reconginze  the 
standard  glove  functions. 

Gloveinit  (  int  glitch  );  -  This  function  initializes  the  glove  and  puts  it  into  high 
resolution  mode.  If  the  glitch  is  set  to  zero,  deglitching  is  deactivated,  otherwise  it  is  activated. 

int  g!ove_ready  -  This  function  returns  a  1  if  there  is  data  to  be  read  from  the  glove,  2  if 
there  is  data  available  and  the  rxflags  are  valid. 

int  glove  read  (  glove_data  *glove  );  -  This  function  reads  information  from  the  glove 
and  places  it  in  the  parameter.  It  returns  zero  if  the  data  has  not  changed.  This  is  important  for 
those  building  glove  programs.  Normally,  programmers  checked  this  manually.  Notice  that  if 
ANY  of  the  values  have  changed,  the  function  will  return  non-zero.  We  still  have  to  check  which 
value  actually  changed. 

The  glove  structure  has  changed  from  other  glove  interface  code.  The  structure  called 
glovedata  is: 

signed  char    x,  y,  z,  rot,  fingers,  keys,  gstatl,  gstat2,  rxflags; 
unsigned  int  it  missed  ; 

The  fingers  are  a  one-byte  bitmap.  There  are  two  bits  for  each  of  the  fingers  not  including 
the  pinky.  The  pinky  has  no  sensors.  The  format  is  (  from  the  segasupp.h  file  ): 

fingers  =  packed  2-bit  values,  0  is  open,  3  is  (tight)  fist: 

Bit  format:  TtliMmRr  for  Thumb,  Index,  Middle,  and  Ring  fingers. 

Program 

The  demonstration  program  is  a  very  simple  program  based  on  the  Virtual  Hand  program 
from  Issue  3.  Instead  of  using  the  Powerglove  pointer  package,  we  use  the  internal  Powerglove 
interface  and  add  Sega  3D  glasses  support.  There  is  a  new  hand.fig  file.  This  figure  file  uses  the 
.pig  file  from  issue  3.  The  program  is  called  3dhand.c. 
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Building  a  Head  Mounted  Display 


In  the  last  issue,  we  discussed  the  methodology  I  intended  to  follow  in  my  quest  for  a  head 
mounted  display.  This  article  documents  the  successes  and  failures  to  this  date  with  that 
methodology. 

Introduction 

My  intentions  are  to  create  a  head  mounted  display  system  that  you  can  build  from  off- 
the-shelf  components.  The  investment  in  components  is  not  small.  To  date,  the  cost  of  this  head 
mounted  display  is  approximately  six  hundred  dollars.  While  this  is  a  large  amount  of  money  for 
many  people,  it  is  nothing  compared  to  eight  thousand.  What  do  you  get  for  $600.00?  You  get  a 
low  resolution/low  performance  head  mounted  display  that  works  good  enough  conduct 
experiments  in  Virtual  Reality. 

One  reason  for  the  low  resolution/low  performance  is  the  type  of  LCD's  used.  We  use 
LCDs  from  Model  470  Casio  2.2"  Color  LCD  televisions,  which  Casio  graciously  donated  for  this 
project.  Of  the  small  televisions  I  looked  at,  the  Casio  televisions  produced  the  best  picture 
quality.  The  horizontal  resolution  of  the  screens  is  less  than  200  pixels. 

Another  reason  for  the  low  resolution/low  performance  is  the  video  source.  I  embarked 
on  "splitting"  the  video  from  a  single  VGA  card  to  keep  from  modifying  the  televisions  or  using 
multiple  VGA  cards.  Initial  tests  were  discouraging  but  eventually  I  was  able  to  split  the  VGA 
image  to  two  different  LCD's.  However,  the  picture  quality  is  less  than  expected.  The  images  are 
visible  but  they  tend  to  jump  and  are  also  a  little  fuzzy. 

The  system  does  work.  I  have  been  using  it  with  Rend386  and  a  Pascal  test  program  to 
build  the  optics  and  enclosure.  For  those  wishing  to  build  a  head  mounted  display,  I  cannot 
guarantee  your  results.  The  speed  of  machine,  LCD  used,  and  VGA-TO-NTSC  converter  used 
alt  effect  the  outcome  of  the  final  system.  Head  mounted  displays  are  primary  components  for  a 
VR  system  and  there  are  other  options,  therefore,  we  will  continue  to  discuss  construction  types. 

This  system's  advantage  over  others  is  the  LCDs,  optics,  and  enclosures  can  all  be  the 
same  no  matter  what  the  video  source  is.  After  creating  an  operational  head  mounted  display,  I 
will  be  looking  into  using  two  separate  PC's  for  driving  the  images. 

If  you  were  expecting  the  quality  of  the  VPL  Eyephones,  you  will  need  to  spend  more 
than  $600.00.  It  should  be  obvious  that  the  technology  involved  in  the  Eyephone  somewhat 
justify  the  cost.  My  intentions  are  to  create  a  head  mounted  display  for  experimentation  purposes. 
Therefore,  I  cannot,  nor  can  PCVR,  take  any  responsibility  for  the  use  of  this  information.  It  is 
experimental,  then  again  so  is  Virtual  Reality.  But  we  will  do  our  best  to  obtain  quality  for  the 
amount  of  money  that  an  average  person  can  justify. 

VGA  to  NTSC 

The  signals  that  come  out  of  the  VGA  cards  cannot  be  used  to  drive  a  television  directly. 
A  television  requires  a  signal  based  on  the  standard  NTSC.  This  is  an  interlaced  signal  with  the 
Red,  Green,  Blue,  and  sync  signals  combined.  To  create  this  signal,  two  things  can  be  done.  1) 
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The  VGA  card  can  be  tricked  into  generating  it  by  replacing  crystals  and  reprogramming  its 
internal  registers.  I  am  no  hardware  whiz  so  I  leave  this  option  to  others.  2)  Purchase  a  VGA-to- 
NTSC  converter. 

There  are  several  converters  on  the  market  in  both  internal  and  external  form.  I  chose  a 
converter  called  PC- Video  Converter  from  Boffin  Limited.  This  converter  converts  CGA,  EGA, 
and  VGA  screens  up  to  640  x  480  x  16.  Including  the  mode  320  x  200  x  256.  This  is  the  mode 
used  by  Rend386.  Most  all  VGA  chips  are  changed  by  this  converter. 

As  a  by-product,  there  is  an  adlib  sound  generation  emulator  included  on  the  card  as  well. 
Most  pieces  of  software  can  play  music  through  it.  Castle  Wolfenstein  recognizes  the  card  and 
generates  a  nice  sound. 

This  is  an  internal  card  with  a  Y  connector  for  the  VGA  card  and  VGA  monitor.  It  is 
connected  as  follows: 


VGA  to 
NTSC 

TV  with  Composite 
video  input 

plug. 


Using  software  provided  with  the  card,  any 
image  from  the  VGA  card  in  the  appropriate 
modes,  including  text  mode,  will  be  displayed  on 
the  TV.  If  the  VGA  monitor  is  a  multi-sync,  the 
image  will  appear  on  it  as  well.  Note  that  the 
TV  must  have  a  composite  video  input.  This 
type  of  input  is  recognized  by  the  RCA  type 


Using  an  old  Commodore  monitor,  I  tested  the  output  from  Rend386  and  found  it  to  be 
just  as  fast  and  clear  as  the  VGA  monitor.  Of  course  the  image  on  the  VGA  monitor  is  better  and 
crisper  but  the  image  looked  pretty  good.  It  was  the  time  I  wished  I  had  a  52"  big  screen  TV  to 
experience  the  full  potential  of  Rend  386. 

The  next  thing  we  need  to  do  is  hook  up  one  of  the  small  LCD  televisions. 

LCD  Video 

As  mention  above,  the  televisions  I  am  using  are  Model  470  Casio  2.2"  Color  LCD. 
These  may  be  purchased  at  any  Target  store  for  approximately  $149.00.  Radio  Shack  used  to  sell 
a  small  LCD  television  that  seemed  identical  but  they  have  discontinued  the  sets.  These 
televisions  are  powered  by  4  AA  batteries  or  a  power  pack.  I  am  using  two  6V  adapters  from 
Radio  Shack.  The  stock  number  is  273-1655  and  they  cost  $16.95.  There  are  probably  cheaper 
ones  available  but  make  sure  that  you  match  the  power  requirement  of  the  television  with  the 
power  supply. 

The  next  step  is  to  hook  up  the  video  to  the  LCD's.  The  televisions  have  external  antenna 
hookups  that  accept  miniplugs.  This  is  a  VHF  input  and  the  output  of  the  converter  card  is 
composite.  We  need  yet  another  converter.  An  RF  modulator  takes  a  composite  video  signal  and 
generates  a  VHF  viewable  signal.  I  again  use  a  Radio  Shack  product.  The  stock  number  is  15- 
1273  and  they  costs  $27.95.  These  modulators  take  an  RCA  input  and  have  an  F  type  connector 
( like  a  cable  TV  cable  ).  This  cable  is  then  terminated  with  a  miniplug  connector,  I  am  looking 
for  an  RF  modulator  circuit  to  cut  down  the  cost  of  purchasing  the  modulators. 

Once  the  system  is  fired  up,  the  televisions  are  tuned  to  either  channel  3  or  4  and  the 
image  appears.  (Boy  is  it  small!)  I  used  the  multi-colored  Virtual  Hand  program  from  Issue  3  to 
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generate  an  image  and  there  was  the  hand  rotating  on  the  mini  televisions.  Well,  so  far  so  good. 
The  next  step  is  to  split  the  video. 


Switcher 

For  stereoscopic  viewing,  we  need  images  for  both  the  left  and  right  eye.  We  cannot 
simply  give  both  eyes  the  same  scene.  We  have  a  system  that  generates,  on  the  LCD,  the  image 
that  appears  on  the  VGA  monitor.  Using  a  chip  called  the  22106,  we  are  going  to  display  both 
the  left  and  right  images  on  two  separate  LCDs. 

Let's  first  begin  with  the  theory.  The  22106  is  an  8x8  cross-switch.  There  are  eight  inputs 
and  eight  outputs.  Any  of  the  inputs  can  be  directed  to  any  of  the  outputs.  What  if  we  used  the 
output  of  the  NTSC  converter  as  the  input  and  switch  this  input  between  two  outputs.  The  first 
output  would  be  to  the  left  eye  LCD  and  the  second  output  would  be  to  the  right  eye  LCD.  Just 
before  we  switch,  we  tell  Rend386  or  whatever  software  executing  to  display  a  different  graphics 
page.  We  have  something  like  this. 


VGA  to 
NTSC 


VGA  Monitor 


Although  the  picture  does  not  show  it,  we  also  have 
two  RF  modulators  between  the  switcher  and  the 
LCDs.  You  may  be  thinking,  why  not  put  the  RF 
modulator  between  the  NTSC  converter  and  the 
switcher.  The  main  reason  is  that  the  output  of  the 
modulator  is  a  VHF  television  signal  and  this  signal 
is  sent  to  the  switcher.  The  switcher  as  we  will  see 
later  is  a  PC/XT  interface  card  inside  the  PC. 
Television  signals  and  the  insides  of  a  PC  do  not 
mix.  Therefore  we  keep  the  signal  composite  and 
there  is  little  distortion.  Using  insulated  coax  cable 
helps  cut  down  on  interference  and  distortion.  This  is  the  plan,  now  let's  look  at  the  circuit. 


22106 
Switcher 


rs; 


Left  eye 

Right  eye 

LCD 

LCD 

Computer  Interface 

The  22106  chip  requires  some  sort  of  interface  in  order  to  be  instructed  to  open  or  close  a 
circuit.  For  simplicity,  we  build  an  interface  for  the  IBM  PC/XT  bus.  This  interface  gives  us 
three  8-bit  parallel  ports  for  the  interface  to  the  22106  chip  as  well  as  other  devices  for  the  future. 
The  circuit  consists  of  the  following: 
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This  circuit  is  loosely  based  on  the  circuit  from  Radio-eiectronics  cited  in  the 
bibliography.  Depending  upon  which  address  line  you  connect  to  pin  6  of  the  8255,  the 
circuit  is  programmed  using  that  address.  The  chip  has  four  address  locations  (  using 
0x280  as  an  example): 


0x280  -  control  location 
0x281  -  Port  A 
0x282  -  Port  B 
0x283  -  Port  C 


The  chip  can  be  programmed  to  allow  each  of  the  ports  to  be  either  input  or  output.  The 
following  values  are  examples  that  can  be  assigned  to  the  control  location  to  indicate  the  status  of 
the  ports. 


Value  Port  A  Port  B  Port  C 

.0x80  OUT  OUT  OUT 

0x8F  IN  IN  IN 


Refer  to  the  Intel  data  book  cited  in  the  bibliography  for  more  values  to  assign  the  chip 
Once  the  chip  has  been  programmed  for  port  status,  we  either  read  or  write  to  the  location  of  the 
particular  ports.  Below  is  some  C  code  to  program  al!  ports  as  output  and  to  put  the  value  of  32 
to  port  A: 
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outport  (  0x280,  0x80  ); 
outport(  0x281,  0x20  ); 

This  is  an  easy  interface  circuit.  The  8255-5  chip  is  very  versatile.  We  are  going  to  use 
the  ports  as  address  and  data  lines  for  the  22106  chip. 

22106  Circuit 

This  chip  is  programmed  by  putting  a  value  on  the  data  bus,  selecting  the  chip, 
determining  whether  to  turn  the  internal  switch  on  or  off,  and  toggling  an  enable  line.  The  circuit 
for  the  22106  part  is: 
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For  a  full  explanation  of  the  chip  and  other  uses,  check  the  byte  magazine  citation  in  the 
bibliography.  Combining  both  of  the  circuits  above  gives  us  the  ability  to  switch  video. 
Programming  the  22106  is  a  fairly  simple  task.  The  value  of  the  internal  cross-switch  to  open  or 
close  is  applied  to  port  A  of  the  8255.  The  22106  chip  is  selected  by  setting  port  b,  line  6  to  high. 
The  chip  accepts  the  value  on  port  a  by  toggling  port  b,  line  7  on  and  then  off 

To  select  an  internal  cross-switch,  the  following  formula  is  used. 

switch  :=  (  out  *  8  )  +  in  +  onoff; 

To  turn  the  switch  on,  set  the  variable  onoff  to  128.  To  turn  the  switch  off,  set  the 
variable  onoff  to  0. 
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As  an  example,  we  turn  the  switch  to  let  video  run  from  input  0  to  output  1  with  the 
following  code: 

outport  (  0x280,  0x80  ); 
outport  (  0x281,  0*8+1+128  ); 
outport  (  0x282,  64  ); 
outport  (  0x282,  192), 
outport  (  0x282,  64  ); 

This  sequence  successfully  toggles  the  appropriate  cross-switch.  To  turn  the  switch  off 
we  change  the  second  line  to  outport  (  0x281,  0*8+1+0  ); 

Final  System 

We  almost  have  a  complete  video  subsystem  for  the  head  mounted  display  The  last  piece 
of  hardware  came  about  because  the  system  as  described  above  does  not  work  adequately  If  you 
build  the  circuits  described  above  and  connect  to  the  LCD  through  the  RF  modulators  you  get 
two  hard  to  see  images  on  each  of  the  televisions.  The  reason  for  the  fuzziness  is  because  the 
switcher  switches  in  the  middle  of  a  sequence  of  video  signals  to  the  LCDs  The  LCDs  need  all  of 
the  signal  to  correctly  trace  the  image  on  the  screens.  To  compensate  for  the  lost  parts  of  the 
signal,  we  introduce  a  good  signal  to  each  of  the  LCD.  This  is  accomplished  through  the  use  of  a 
second  PC  or  a  monochrome  card.  The  PC  allows  a  second  video  to  coexist  with  a  VGA  card  if 
it  is  monochrome.  The  monochrome  card  is  necessary  to  project  a  black  screen. 
The  following  diagram  illustrates  the  hookup  of  the  entire  system: 
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The  monochrome  card  should  be  programmed  to  enter  graphics  mode  display  a  black 
screen  and  wait  until  a  key  is  pressed.  This  is  our  good  signal  to  the  LCDs.  Each  of  the  LCDs 
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receive  the  good  signal.  In  the  diagram  above,  point  a  is  the  intersection  of  the  good  signals  with 
the  LCDs.  At  this  connection  ONLY  the  hot  wire  should  be  connected,  not  the  ground.  The 
LCDs  are  using  their  own  ground  signals  in  addition  to  the  hot  of  the  good  signal. 

This  may  seem  like  a  kludge,  but  it  works.  A  further  enhancement  can  be  made  by  using 
to  separate  video  sources  for  the  black  screen.  Each  source  would  drive  a  separate  LCD. 

Future 

I  am  not  finished  with  the  above  circuit.  I  intend  to  incorporate  the  RF  modulators  and 
two  separate  video  source  into  the  circuit. 

Software 

The  software  called  switch. pas  on  the  enclosed  disk  does  the  following: 

1)  setup  up  graphics  pages  0  and  1  with  two  different  images. 

2)  sets  the  8255  chip  to  all  output. 

3)  clears  all  internal  cross-switches. 

4)  Switches  pages  and  internal  switches  until  q  is  pressed. 

Next  Issue 

The  next  issue  deals  with  the  optics  involved  in  creating  a  head  mounted  display.  For 
those  interested  in  following  my  footsteps,  please  feel  free  to  contact  me  if  you  have  any 
problems. 

Addresses 

The  address  for  Boffin  is  (  PC-Video  Converter,  $199.00  ): 
Boffin  Limited 

2500  West  County  Road  42  #5 
Burnsville,  Minnesota  55337 
(612)  894-0595 
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Graphics 


In  the  issue  3,  we  discussed  the  basics  behind  using  a  matrix  in  computer  graphics 
calculations,  performing  object  translations  and  object  scaling.  In  this  issue,  we  look  at  rotating 
an  object  about  one  of  the  three  coordinate  axis. 

Before  "we  can  rotate  an  object,  we  need  to  designate  which  axis  should  be  used  for  the 
rotation.  If  we  choose  the  X  axis  for  the  rotation,  the  object  rotates  'about'  this  axis.  The  first  set 
of  calculations,  rotate  objects  parallel  to  the  chosen  axis. 

If  we  were  to  look  down  the  positive 


part  of  an  axis  toward  the  origin,  objects 
rotate  in  a  counterclockwise  motion  when 
given  positive  rotation  angles.  This  is  true 
for  each  of  the  three  axes. 

Before  rotate  three-dimensional  objects,  let's 
skip  back  to  two  dimensions. 

X 


Figure  t 


Two- Dimensional  Rotations 

We  speak  of  rotation,  as  moving  a  point  in  a  circular  path  from  one  position  to  another. 
This  circular  path  is  determined  by  an  angle  of  rotation.  Figure  2  illustrates  a  rotation  of  a  point 
from  position  (x,y)  to  (xl,yl)  by  the  angle  of  rotation  0.  The  distance  d  stays  the  same  from  the 
original  point  to  the  new  point.  The  original  degree  of  rotation  is  noted  by  §.  Now  using  some 
trigonometry  we  can  come  up  with  two  equations  that  give  us  the  new  location  of  the  point. 

The  new  angle  of  rotation  is  the  sum  of  <J>  and  9.  If  we  take  the  cosine  of  that  sum  and 
multiply  it  by  the  value  of  d,  we  obtain  the  new  jc  value.  If  we  take  the  sin  of  that  sum  and 
multiple  by  the  value  of  t/,  we  obtain  the  new  j'  value.  The  equations  are 

xi  =</cos(<|>  +  e  ) 

yl=rfsin((fr  +  e) 
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From  Figure  2  we 
also  see  that  we  have 
two  additional 
formulas 

x  =  r  cos  <|> 
y  =  r  sin  <|> 

If  we  take  the  two 
original  equations 
and  apply  some 
standard 
trigonometric 
identities  to  them,  we 
create  two  more 
equations  should  be 
simplied  with  the  two 
equations  above. 


xl  =  r  cos  ( <J>  +  0  )  becomes  r  cos<j>  cosG  -  r  sin<|>  sin0 
yl  =  rsin((|>  +  8)  becomes  r  sin<|>  cosG  +  r  cos<(>  sinG 

By  substitution,  we  end  up  with  the  following  equations. 

xl  =  x  cosG  -  y  sin0 
yl  =  y  cos0  +  x  sinG 

;  ~  ;<These  two  equations  rotate  a  single  two-dimensional  point.  Out  objective  goal  is  to  move 
onto  three-dimensional  points  which  have  the  third  z  component. 

Thr^p-Dimoiisional  Rotation 

There  are  three  different  sets  of  equations  for  three-dimensional  rotation  because  of  the 
three  different  axis.  Notice  that  when  we  were  doing  the  two-dimensional  rotation,  the  rotiation 
was  about  the  Z-axis.  So  for  three-dimensional  rotation  about  the  Z-axis,  we  use  the  same 
equations  and  keep  the  Z  component  stable. 

xl  =  x  cosG  -  y  sinG 
yl  =  x  sinG  +  y  cosG 
zl  =  z 
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If  we  convert  this  to  our  matrix  notation,  we  obtain  the  matrix 

r  cos9  sinG  0 
I  -sinG  cosG  0 
I     0      0  1 

L  o     o  o 


The  remaining  two  rotations  are  simple  variations  of  the  equations  and  matrix  above.  To 
create  the  rotation  for  the  x-axis,  we  perform  a  rotation  of  the  coordinate  parameters.  Thus  x 
takes  z's  place,  y  takes  x's  old  place,  and  z  takes  y s  old  place.  The  equation  becomes: 

yl  -  y  cosG  -  z  sinG 

zl  =  y  sinG  +  z  cosG 
xl  =  x 

and  the  matrix  is 

10  0       o  1 

0    cosG  sinG    0  I 

0    -sinG  cosG    0  I 

0       0  0         1  J 


We  do  the  same  for  the^y-axis  rotation. 

zl  =  z  cosG  -  x  sinG 
xl  =  z  sinG  +  x  cosG 
yl  =y 

and  the  matrix  is 

cosG  0  -sinG  0  1 
0  10  o  I 
sinG  0  cosG  0  I 
0      0      0        1  J 


Conclusion 

These  rotation  matrices  rotate  an  object  0  degrees  about  one  of  the  three  coordinate  axis. 
This  is  different  from  rotating  about  an  axis  that  is  parallel  to  a  coordinate  axis.  We  tackle  that 
problem  in  the  next  issue.  The  demonstration  program  is  on  the  diskette  and  is  called  axis3.c. 
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Last  Page 


Next  Issue 

The  next  issue  of  PCVR  will  be  dedicated  to  head  tracking  technology.  We  will  look  at  the 
technology  currently  available  and  determine  which  we  can  build  ourselves. 

Software 

If  you  wish  a  diskette  containing  the  software  from  all  previous  issues  that  did  not  include  a 
diskette  (  1,  2,  3  ),  send  $5.00  and  your  diskette  preference. 

Submissions 

We  are  always  looking  for  suggestions,  comments,  and  new  ideas.  To  submit  an  article,  send 
a  diskette  in  any  of  the  following  formats. 

1)  ASCII  with  illustrations  in  GIF  or  PCX  format 

2)  Word  For  Windows  1.1,1.2  or2.0 

3)  Word  Perfect  5.0,5.1 

Address:  PCVR 

1706  Sherman  Hill  Rd.  #A 
Laramie,  Wyoming  82070 

If  we  use  your  article,  we  will  credit  your  account  for  the  issue  that  the  arcitle  appears. 

I  can  be  contacted  at  gradecki@rodeo.uwyo.edu.  If  you  are  interested  in  conversing  about 
topics  that  appear  in  the  magazine,  drop  me  a  line. 

Errors 

There  are  a  couple  of  errors  in  the  Third  Issue  that  I  would  like  to  clarify.  In  the  Virtual  Hand 
article,  under  the  heading  Setup  Systems,  I  mention  calling  compute_view_factor  before 
setup__render.  The  Rend386  documentation  says  to  call  setup_render  first.  In  the  program,  the 
compute_polar  function  is  NOT  necessary  and  can  be  removed.  I  would  recommend  increasing 
the  z  eye  distance  as  well.  Finally,  in  the  routine  mainjoop,  the  if  statement  for  the  roll  of  the 
glove  should  have  the  statement  update_segment  ( thehand  );  before  the  redraw  =  1  statement. 
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